The present invention relates to a management method according to the preamble of the attached claim 1 for managing a telecommunications network, and to a telecommunications network management system according to the preamble of the attached claim 6. The telecommunications network to be managed may be e.g. a SDH (Synchronous Digital Hierarchy) network, a PDH (Plesiochronous Digital Hierarchy) network, or a combination of such networks.
The basic situation in network management is usually such that an operator managing a telecommunication networks, e.g. a telephone company, has a plurality of customers (i.e. network users) in addition to the physical network. The operator sells the customers various services that utilize the network. (A public network will be used herein as an example; in principle, however, the same description applies to a private operator managing e.g. an organization network). To meet customers"" data transmission requirements in the physical network, the operator utilizes a number of facilities or operative processes for the provision of customer services. These operative processes can be divided into groups in accordance with the functions for which they are intended:
Service Provisioning taking care of the performance of customer services, including e.g. invoicing customers for services.
Operation and Maintenance for keeping the network operative to allow the usage of customer services. One of the most important functions in this respect is the supervision and repair of network faults.
Planning and Development, the function of which is to develop network operation so as to better meet customers""needs and to increase the overall profitability of the operator enterprise.
As appears from the above, network management takes place on several different levels, depending on the extent to which the functions to be performed on a specific level are associated with the overall management of the operator enterprise. The management of a telecommunications network is generally divided into four different levels, which are from bottom to top as follows:
network element management layer,
network management layer,
service management layer, and
business management layer.
This division is used e.g. in the ITU-T (the former CCITT) recommendation M.3010, which specifies a kind of framework for the management architecture of a telecommunications network. The bottom layer below the above four layers is the equipment itself; these equipments are managed by installation and field engineering tools.
The network element management layer means the management of an individual network element (such as a multiplexer or a cross-connection device) as a separate component without simultaneously paying attention to the condition of the network or other network elements. The majority of so called xe2x80x9cnetwork managementxe2x80x9d systems commercially available today are actually network element management systems within this layer.
The network management layer is concerned with the management of the entire telecommunications network, such as overall management of network connections. One example is the creation of connections and the end-to-end supervision of their condition. This means that e.g. alarms detected on equipment are not just displayed against that equipment, but they are also propagated to show what services (paths and circuits) are affected by the fault, if any. The present invention is positioned in this layer.
As distinct from the above, the service management layer is not concerned with technical network management. It takes care of e.g. customer data, supervision of services provided to customers, invoicing for services, and considering needs for services of different types.
The business management layer is used to monitor and plan the business activities and economy of the entire enterprise, resulting in decisions affecting the lower levels.
At present, network management systems are changing into systems that manage the telecommunications network as a whole, whereas conventional management systems have handled only the remote control of transmission equipment, especially monitoring alarms produced by the equipment. In conventional network management methods, configuration changes, such as creation of new end-to-end connections, have been laborious and time-consuming, as the end result consists of several configuration events the prerequisite of which is that the maintenance staff of the network first gets an overall view of the situation and then decides on configuration changes required in individual network elements. In new network management systems, on the contrary, an overall view of the network and its condition is produced within the system, and the system itself gives the required configuration commands to each transmission equipment. As a consequence, all configuration changes can be performed significantly more rapidly than previously. Such developments have been accelerated by the freeing of competition in the field of telecommunications.
The above-mentioned recommendation M.3010 specifies the management architecture as shown in FIG. 1. The architecture basically consists of one or more operations systems OS connected to a data communication network DCN communicating with an actual telecommunications network which is to be managed and which includes the network elements NE managed. It is to be noted that the connections of the data communications network and those of the telecommunications network are logically distinct, although they can be implemented physically in one and the same cable. Logically, there are thus two networks: (a) a network providing services to customers, and (b) a network maintaining the service provisioning network. The management of certain transmission equipments (network elements) further requires a separate Mediation Device MD, which mainly acts as a protocol converter between a Q3 interface complying with the recommendations and transmission equipments that do not understand the protocol applied in the interface but use their own proprietary protocol. New SDH equipment, for instance, can be connected directly to the Q3 interface, whereas older PDH equipment requires a Mediation Device.
In practice, a management network for a combined SDH and PDH network may be e.g. such as shown in FIG. 2. Users (network operator staff) sitting at the operation centre use network management work stations WS connected to a separate local area network WSN, which may be e.g. an Ethernet network. The management system is typically distributed in several computers of the local area network, one of the computers being a dedicated application server SRV having a database DB containing information necessary for managing the network. In its practical embodiment, the local area network further comprises e.g. necessary back-up devices (like DAT drives or mirrored disks) and event-logging printers (not shown).
The management system is connected via the above-mentioned Q3 interface e.g. to the SDH network. A variety of alternatives have been defined for the Q3 interface, so that the interface may be e.g. an X.25 type packet switched interface or an Ethernet LAN interface. (The packet switched interface is useful if the operator in charge of the network management also otherwise uses a packet switched network.) In practice, control channels between the SDH network elements 21 are established in the overhead bytes of the STM-N signal (N=1, 4, 16), so that control signals between SDH equipments propagate with the payload signal (that is, also in the same physical network). Such control channels established in the overhead bytes are called Embedded Control Channels, and they are formed e.g. in the STM-1 frame by the section overhead bytes D1 to D12.
PDH equipments, on the contrary, need manufacturer-specific solutions, wherefore they have to be connected to the management system through a separate mediation device 22.
The management system may also be hierarchical so that different geographical areas have their own smaller management systems that together form an integral management network. For instance, a management system covering one country may be divided geographically into smaller management systems operating in different parts of the country. Each smaller management system takes care of the management of the network portion in the concerned geographical area. In the example of FIG. 2, management systems MS1 and MS2 geographically apart from each other form together a single common management system and management network.
Network management standards are nowadays largely based on so-called object-oriented descriptions, though the standards do not require the use of this technique. Objects are data structures in a network management system, which describe the functions and state of a network component. An object is thus an element having certain attributes (xe2x80x9cI am like thisxe2x80x9d) and certain operations (xe2x80x9cI can do these thingsxe2x80x9d). (In the object-oriented approach, objects with the same data structure (attributes) and the same behaviour (operations) are grouped into a class. A specific implementation of an operation is called a method and each object is said to be an instance of its class.) A typical object is e.g. a cross-connection device with certain attributes (cross-connections that are active) and certain methods (e.g. make cross-connection and release cross-connection).
In a telecommunications network management system, objects can be physical ones or logical ones. Physical objects are elements that form part of the physical network. Such objects are e.g. the above-mentioned network elements (a network element is any piece of telecommunication equipment that works as a single unit to provide telecommunication functions) or physical connections (such as optical fibres, twisted pair cables, coaxial cables, radio links or satellite links). Logical objects are logical entities that do not form a single piece of the physical network. Such objects are e.g. paths and circuits. (A path is a connection of a fixed bit rate and format between two physical interfaces within the network. A circuit is a connection set up for a customer, between two physical interfaces on the boundary of the network. Thus, a circuit usually comprises several consecutive paths.)
A network object may have a number of different attributes. Some attributes (such as xe2x80x9cfault statexe2x80x9d) are used by several different types of object. In addition, for some types of network object (such as a route), it is convenient to define an attribute which consists of a collection of other attributes. Typical attributes are e.g. xe2x80x9cavailability statusxe2x80x9d, xe2x80x9cfault statexe2x80x9d and xe2x80x9coperational statexe2x80x9d. The attributes have different possible values, e.g. fault state can have values:
OK. There are no problems.
Warning. There are outstanding faults, but these do not effect services.
Degraded. Some or all of the services provided by the object are degraded.
Failed. All the services provided by the object are lost.
Unknown. The fault state of the object is unknown.
The xe2x80x9coperational statexe2x80x9d, in turn, can have e.g. two different values:
Enabled. The object can operate, either completely or in part.
Disabled. The object cannot operate at all.
The architecture of a network management system may also be presented in a simplified form as shown in FIG. 3. Users (people managing the telecommunications network) sitting at an operation centre and monitoring the situation of the network on the display of a work station start and terminate applications 30 to manage the network. (The applications are thus very transient elements). Applications are part of the system containing the user interface functionality. The applications offer users the above-described services, such as end-to-end connection management, network optimisation and fault management. The applications converse with the management system core 31, which is a background process e.g. keeping record of events and maintaining a management database 32, i.e. a view of the network. In addition, the core gives the applications 30 information about the managed objects when the applications request such information. Correspondingly, the applications can change the attributes of an object in the database 32, in which case the function of the core is to inform the concerned network element 33 (which may also be the Mediation Device) of the change. The network element comprises its own (limited) database 34, which contains objects related to this specific element.
In principle, the database 32 contains the data of all of the physical elements of the network. It also contains a number of logical entities, such as objects describing customers and (end-to-end) customers connections. The data are interrelated so that an inquiry can be made e.g. about the connections of a specific customer or the customer on a specific connection. (It is to be noted that the physical network comprises no element describing the entire customer connection, but the network comprises a plurality of separate elements each describing a small portion of a connection.)
While an application is using objects, they must be held in the application""s memory. When an application wishes to change these objects, they must first be locked to prevent other applications from changing them at the same time.
Due to the complex dependencies between objects, holding one object in memory may require another to be held as well. Similarly, locking one object may require others to be locked. To give an example, when an application locks a path object so as to change its route, it must also lock the objects that represent the network elements that will change as a result.
The complete model used to represent the network is almost always very large. The network can have tens of thousands of pieces of equipment and each of these can have a number of objects associated with it, whereby there can be even fifty to a hundred thousand objects representing a network. In practice, this is too much information to be kept in central memory at the same time. Therefore, the same technique can be applied both to throwing objects away from the memory when no longer required (so as to minimize memory use) and unlocking them. Consequently, what is said about lock management in the following also applies to memory management.
The dependencies between the objects are, in general, hidden from the application (and user) so that the application just locks the path and the network elements are locked automatically. Similarly, when the application has completed its operation it frees the object from memory and/or unlocks it, and all the other objects on which it depends are freed and/or unlocked.
The problem behind the present invention is that of this unlocking and/or freeing, i.e. the problem how to check the dependencies between the objects to be able to perform this unlocking and/or freeing in a correct way. The solution to this problem is non-trivial, because the dependencies between objects can be cyclic, i.e. object A depends on object B which depends on object C which depends on object A. (It is to be noted that the problem of dependency checking is related only to unlocking, not to locking, because when an object must be locked, it is clear that all the objects that this object references must be locked. However, when the object is unlocked, other operations going on at the same time may require the same object to be kept still locked, although the operation that originally caused the locking does not any more require this.)
In the prior art there are a number solutions to this problem of dependency checking. The solutions fall into two broad categories: (a) reference counting and (b) garbage collection. These two categories are illustrated in the following.
In the reference counting method, a count is associated to each object. Each time an object is referenced by another object, the count associated with that object is raised. Each time the reference is removed the count is reduced. When the count reaches zero, the object can be freed and/or unlocked. Also, any references from that object to others can be removed as well, possibly causing further freeing and/or unlocking to take place.
FIGS. 4a . . . 4e demonstrate how the reference counting method works. In the figures, two different objects, A and B, have been shown, each being marked by a box labelled by the corresponding letter (A or B). Associated to each object box is the count box, labelled by the value of the corresponding counter. Initially (FIG. 4a), objects A and B have no references to them, whereby the associated counter values are zero. Then (FIG. 4b), something from outside references A (as shown by an arrow), whereby its reference count is incremented to one. (In practice, a reference from an object to another, indicating a dependency between those objects, can be implemented in any possible ways, e.g. by means of a pointer word, i.e a binary number the value of which corresponds to the object it is pointing to.)
After that (FIG. 4c), object A references object B, so the reference count of object B is incremented. If the external reference to object A is then removed, the count of object A is reduced to zero (FIG. 4d). When this happens, all references from object A to other objects are also removed (FIG. 4e). Thus, in the example, the reference count of object B is also reduced to zero.
This kind of a solution is insufficient in a network management system, as it cannot cope with circular dependencies. Objects which are mutually dependent end up keeping the count at a value greater than zero because they refer to each other even though nothing else refers to them. This is illustrated in figures 5a . . . 5d. 
The initial situation (FIG. 5a) is such that object A references object B and something from outside references object A. Then (FIG. 5b), object B creates a reference back to object A; this increments the reference count of object A to two. If the external reference is now removed, the reference count of object A is still one because object B is still referencing it (FIG. 5c). This leads to the situation of FIG. 5d, where neither object A nor object B can be freed or unlocked because each has a reference count of one, but the only things actually referencing the objects are the objects themselves, i.e. the objects could actually be unlocked but the incorrect value of the reference count prevents it.
The second common form of dependency checking, called garbage collection, is based on a different approach. In garbage collection, all the links from a known root object or objects are periodically followed to all other objects, and each object that is reachable is marked as being still in use. Then all other objects that are no longer reachable are freed and/or unlocked.
What is used as the root object or objects varies from system to system depending on how the objects are designed to be linked together. For example, if garbage collection were used for the network management system, the root objects would be those objects that had been specifically fetched and/or locked by the application using them; any objects that could no longer be reached from those objects could be freed and/or unlocked.
The example of FIGS. 6a to 6d shows how garbage collection works. FIG. 6a shows a group of objects A . . . F with links between them, including a loop dependency between two objects, D and E. FIG. 6b shows two links being removed, with the result that objects D and E are no longer referenced by any other objects. Some what later (FIG. 6c), all the links reachable from the known root object (A in the example) are followed and all the reachable objects are marked. Reachable links and objects are shown in solid lines in FIG. 6c, the others in dotted lines. After all reachable objects have been found, those that are no longer reachable are freed or unlocked. The result is shown in FIG. 6d. 
This approach deals with the problem of circular references (as demonstrated by the removal of D and E in the example), but is unsuitable for network management systems for the following reason.
Garbage collection does not find the unused objects as soon as they are unused. It is unacceptable for a (rapidly operating) network management system to have a delay between when an object is no longer used and when it is unlocked, as there may be many other applications waiting to use the object.
The purpose of the present invention is to provide a novel solution for the locking management in a telecommunications network management system, not showing the above-mentioned drawbacks. This is achieved by means of the method according to the invention, which is characterized by what is set forth in the characterizing portion of the attached claim 1. The system according to the present invention is, for its part, characterized by what is set forth in the characterizing portion of the attached claim 6.
The dependencies between objects in the network management system can be regarded as a data structure known as a Directed Graph (DG). This represents the objects as nodes in the graph with directional links between the nodes as the dependencies. Following the links from a node can lead back to that node; it is this feature that leads to e.g. reference counting in its basic form being inapplicable to lock management, as mentioned earlier.
A related data structure is the Directed Acyclic Graph (DAG); this is identical to the Directed Graph, except that it has the property that no node can link back to itself either directly or indirectly. The idea of the invention is to add to the system an additional data structure so that the dependencies between the objects can be viewed in a DAG form, to maintain this structure as a DAG after any changes in dependencies between the objects, and to use simple reference counting in connection with this additional data structure to decide when objects can be unlocked and/or freed. A technique for converting DGs to DAGs already exists (see Aho, Hopcroft and Ullman: Data Structures and Algorithms, pp 222-226, Addison-Wesley, 1985, ISBN 0-21-00023-7). This technique works by identifying all nodes in the old DG that form a circular dependency and combining them to form a single node in a new DAG.
In the present invention this technique is applied to the problem of dependency management in a telecommunications network management system, with the inclusion of various optimisations to minimise the overhead involved in maintaining the data structure. Thus, the idea of the present invention is to maintain in the system an auxiliary data structure that does not include cyclic dependencies between the objects, and to utilize reference counting in connection with this data structure. The system according to the present invention can be viewed as having two overlapping data structures: a first data structure including the objects and the references between them, and a second (auxiliary) data structure including the groups (of mutually dependent objects) and the references between them.
The advantage of the present invention over existing reference counting approaches is that arbitrary circular dependencies can be coped with. The advantage of the present invention over the known garbage collection method is that by means of the present invention an object becomes unlocked as soon as it is no longer required to be locked. The present invention also has the benefit of spreading the computational load over each lock/unlock operation rather than having it all occur at once.